home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15438 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB
  1. Path: grimsel.zurich.ibm.com!usenet
  2. From: wgk@zurich.ibm.com (Keith Whittingham)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Is this a memory leak?
  5. Date: 5 Apr 1996 14:07:33 GMT
  6. Organization: IBM Research, ZRH
  7. Message-ID: <4k39f5$lhn@grimsel.zurich.ibm.com>
  8. References: <4jv214$gv7@insosf1.netins.net> <4k02v5$tu7@grimsel.zurich.ibm.com> <4k2vku$s82@werple.net.au>
  9. Reply-To: wgk@zurich.ibm.com
  10. NNTP-Posting-Host: pine.zurich.ibm.com
  11. X-Newsreader: IBM NewsReader/2 v1.00
  12.  
  13. In <4k2vku$s82@werple.net.au>, davidw@werple.net.au (David White) writes:
  14. >wgk@zurich.ibm.com (Keith Whittingham) writes:
  15. >
  16. >
  17. ME>>The dto, ~TopClass, is a going to try and free some memory at the address
  18. ME>>0x000 but, by a quirk of implmentation, will probably not blow up (as a 
  19. ME>>simple call to free(0) would). Instead the compiler probably generates
  20. ME>>code to check that the object address is 0, it so there is no deallocation
  21. ME>>of the memory.
  22. >
  23. >The use of 0 as a pointer is not the address 0x000. It is a null pointer
  24. >as defined by the language. Implementations are not even required to use a
  25. >bit pattern of all zeroes as a null pointer. They can use any value they
  26. >like, as long as it will not also be used as a real address. Furthermore,
  27. >rather than being a quirk of implementation, the language guarantees that
  28. >deleting a null pointer will do nothing. 
  29. >
  30.  
  31. Er, I don't think I agree. 
  32.  
  33. The line of code (if I remember correctly) was:
  34.  
  35.    bury = 0;
  36.  
  37. 'bury' being a pointer to some element. bury *is* a pointer and it is 
  38. assigned the value 0. 0 is the same as 0x0000. The line of code:
  39.  
  40.    bury = NULL;
  41.  
  42. may of course set bury to some other value.
  43.  
  44. If, for some compiler, a NULL pointer was implemented as a bit pattern
  45. of all ones then we could expect the code:
  46.  
  47.    bury = 0;
  48.    delete bury;
  49.  
  50. to have some very strange behaviour. Whereas
  51.  
  52.    bury = NULL;
  53.    delete bury;
  54.  
  55. would be 'safe' although undesireable.
  56.  
  57. In the real world most, if not all, compilers (I know of no exceptions) 
  58. use the value 0 for a NULL pointer. As the original poster is trying 
  59. to understand why his compiler is behaving the way it is I don't think
  60. that things need to be complicated with pathological cases.
  61.  
  62. "Quirk of implementation" should have read, as you point out,
  63. "quirk of the language". I believe it is a 'quirk' as it is simply there 
  64. to stop automatic deletion of objects for which construction failed 
  65. due to lack of memory. I would consider explicit use of this 'feature' 
  66. shoddy programming but then I'm an awkward sod...
  67.  
  68. Keith
  69.  
  70.  
  71.  
  72.